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Remarks 

Applicants' representative thanks the Examiner for the courtesies extended during 
the telephonic conference on February 12, 2007, with Francis Dunn. During the 
conference, there was discussion regarding overcoming the rejections of the subject 
claims, including discussion regarding claims 1,11, and 23, and more particularly, 
discussion regarding "a multiple active result set (MARS) header," and "a data field." 
There was also discussion regarding the Office Action Summary where claims 14-22, 24, 
and 25 were indicated as being allowed; however, the Examiner clarified and stated that 
the Office Action Summary should have indicated that those claims are withdrawn. 

Claims 1-30 are currently pending, and claims 1-13, 23, and 26-30 are presently 
under consideration, in the subject application. Claims 1, 11, 12, and 23 have been 
amended as shown on pages 2-7 of the Reply. Claims 14-22, 24, and 25 have been 
withdrawn. No new matter has been added, and amendments made herein will not 
require a search. 

Favorable reconsideration of the subject patent application is respectfully 
requested in view of the comments and amendments herein. 

I. Rejection of Claims 11-13 Under 35 U.S.C. $ 101 

Claims 1 1-13 stand rejected under 35 U.S.C. § 101 on the grounds that claim 11- 
13 are directed to non- statutory subject matter. It is requested that this rejection be 
withdrawn for at least the following reason. The subject claims produce a useful, 
concrete, and tangible result and are therefore within the bounds of statutory subject 
matter, in accordance with 35 U.S.C. §101. 

Title 35, section 101, explains that an invention includes 
"any new and useful process, machine, manufacture or 
composition of matter."... Without question, software code 
alone qualifies as an invention eligible for patenting under 
these categories. Eolas Techs., Inc. v. Microsoft Corp., 399 
F.3d 1325, 1338-39 (Fed. Cir. 2005) (holding that 35 
U.S.C. § 101 did not limit inventions or components of an 
invention to structural or physical components {e.g., non- 
software components). Rather, every component, including 
software components, of every form of invention deserves 
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the protection of § 271(f) because it is patentable subject 
matter under 35 U.S.C. § 101). 

The claimed subject matter, as recited in the subject claims, produces a useful, 
concrete, and tangible result. For example, claim 1 1, as amended, recites: A computer- 
implemented system that facilitates communication in client/server networks comprising: 
a server device in communication with a client device via a tabular data stream (TDS) 
protocol in a network environment; and the TDS protocol comprising a query 
notification header with a data field that requests updates related to a query at a time 
the communication is initially established to facilitate communication between the 
server device and the client device, the updates comprise information associated with at 
least a change to the query. 

The claimed subject matter is a system that can be implemented by a computer 
and can include a client device and a server device. The system can facilitate 
communication between the client device and the server device in part by including, as 
part of the TDS protocol, a query notification header with a data field that can request 
updates regarding a query at the time the communication is established. The request can 
be for updates as to any changes with respect to the query. Such updates can facilitate 
mitigating having to periodically re-ask the server for information as to any changes to 
the initial query. 

Thus, the system includes physical components, as it is a computer-implemented 
system, and further involves a client device and a server device. Further, the system can 
produce a useful, concrete, and tangible result, as it can utilize a query notification header 
with a data field to request updates related to a query, such as updates as to changes 
associated with the query, at the time the communication is initially established in order 
to facilitate communication between the client device and the server device. 

In view of at least the foregoing, the subject claims are properly limited to 
statutory subject matter in accordance with 35 U.S.C. § 101, and the rejection should be 
withdrawn. 
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II. Rejection of Claims 11-13 Under 35 U.S.C. $ 102(b) 

Claims 11-13 stand rejected under 35 U.S.C. § 102(b) as being anticipated by 
Anand, et al. (US 5,974,416) ("Anand, et a/."). Withdrawal of this rejection is 
respectfully for at least the following reason. Anand, et al. does not disclose each and 
every element of the subject claims. 

For a prior art reference to anticipate, 35 U.S.C. § 102 
requires that "each and every element as set forth in the 
claim is found, either expressly or inherently described, in a 
single prior art reference." In re Robertson, 169 F.3d 743, 
745, 49 USPQ2d 1949, 1950 (Fed. Cir. 1999) {quoting 
Verdegaal Bros., Inc. v. Union Oil Co., 814 F.2d 628, 631, 
2 USPQ2d 1051, 1053 (Fed. Cir. 1987)) (emphasis added). 

The claimed subject matter relates to an enhancement of a Tabular Data Stream 
(TDS) protocol that can be employed for client/server communication networks. The 
claimed subject matter can employ a Multiple Active Result Sets (MARS) feature, which 
can include a data field header, for example. Such data field can identify, to a server, the 
number of pending requests known by a client, and thereby facilitate query 
synchronization, regardless of buffer sizes employed in the client-server communications 
network. The client's reporting of the number of pending requests to the server can 
facilitate synchronizing execution of queries, for example, where the server already has 
completed processing of previous requests. This can typically mitigate inconsistent 
server behavior related to instances where buffer zones are waiting to be read by the 
client. 

In addition, the claimed subject matter can include a query notification header as 
part of the enhanced TDS protocol. At the time of establishing the query, the server can 
be asked to provide the client with future update results related to the query. As such, a 
requirement for periodically re-asking the server of any changes to the initial query can 
be mitigated. Accordingly, the manner of sending such notifications {e.g. channels for 
sending the notification), as well as the set up for notification is established at the time of 
the query, and does not require changes to be made on the client side. Moreover, the 
query notification feature allows creation of middle tier type caches, which can be 
transparent to the client. 
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In particular, independent claim 1 1, as amended, recites: the TDS protocol 
comprising a query notification header with a data field that requests updates related to 
a query at a time the communication is initially established to facilitate communication 
between the server device and the client device, the updates comprise information 
associated with at least a change to the query. Anand, et al, does not disclose this 
distinctive feature of the claimed subject matter. 

Rather, Anand, et al. discloses a tabular data stream format, specifically, the 
Advanced Data TableGram (ADTG) format, for the transmission of tabular data between 
a client and a server. (See Abstract). Anand, et al. uses the ADTG format to marshal 
data for transfer between a client and server. (See col. 2, Ins. 12-16). The marshaled 
resultsets of database queries, i.e., table rows containing updates made to them by 
applications, and status information for each row that contained the changes, are 
converted into an ADTG message. (See col. 2, Ins. 16-21). In addition to receiving 
query results from the server, the client updates the database using an ADTG message 
containing both the updated data and the original data. (See col. 3, Ins. 5-8). Anand, et 
al. further discloses utilizing tokens, including a token, whose purpose is to establish 
global parameters for the ADTG message, that may include a field for tracking updates to 
the format of ADTG messages. (See col. 8, Ins. 12-22). 

However, unlike the claimed subject matter, Anand, et al. is silent regarding a 
data field that requests updates related to a query, such as information regarding changes 
to the query, at a time the communication is initially established. Instead, Anand, et al. 
simply discloses tracking updates. Requesting updates related to a query is clearly 
different from tracking updates. Further, Anand, et al. fails to disclose that the requests 
for updates are made at the time the communication is initially established. Moreover, 
Anand, et al. is silent regarding requesting updates to obtain updated information as to 
any changes to the query. 

In contrast, the claimed subject matter can include a query notification header 
with a data field that can request updates related to a query at the time the communication 
is initially established. The request can be for updates as to any changes with respect to 
the query. Such updates can facilitate communication between the client device and the 
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server device, as such updates can facilitate mitigating having to periodically re-ask the 
server for information as to any changes to the initial query. 

In view of at least the foregoing, Anand, et al. does not disclose each and every 
element recited in independent claim 1 1 (and associated dependent claims 12 and 13). 
Accordingly, it is believed that the subject claims are in condition for allowance, and the 
rejection should be withdrawn. 

III. Rejection of Claims 1-2, 4-9, 23 and 26-28 Under 35 U.S.C. § 103(a) 

Claims 1-2, 4-9, 23 and 26-28 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Anand, et al. in view of Jordan, II, et al. (US 5,415,805) ("Jordan, II, et 

airy 

To reject claims in an application under § 103, an examiner 
must establish a prima facie case of obviousness. A prima 
facie case of obviousness is established by a showing of 
three basic criteria. First, there must be some suggestion or 
motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in 
the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation 
of success. Finally, the prior art reference (or references 
when combined) must teach or suggest all the claim 
limitations. See MPEP § 706.020'). The teaching or 
suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the 
prior art and not based on applicant's disclosure. See In re 
Vaeck, 947 F.2d488, 20 USPQ2d 1438 (Fed. Cir. 1991). 

The claimed subject matter generally relates to an enhanced Tabular Data Stream 
(TDS) protocol that can facilitate communication between a client device and a server 
device. In particular, independent claim 1 (and similarly independent claim 23) recites: a 
tabular data stream (TDS) protocol that comprises: a multiple active result set (MARS) 
header, and a data field that is part of the MARS header and identifies a number of 
pending requests known by the client device to the server device. Anand, et al. and 
Jordan, II, et al., alone or in combination, do not disclose, teach, or suggest this 
distinctive feature of the claimed subject matter. 
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Anand, et al. discloses a TDS format for the transmission of tabular data between 
a client and a server. {See Abstract). However, unlike the claimed subject matter, 
Anand, et al. fails to disclose a TDS protocol that comprises a data field that identifies, to 
the server device, the number of pending requests known by the client device. Rather, 
Anand, et al. simply discloses that when a client process requests data from a database, 
the script or application issues a query to the server. {See col. 5, Ins. 15-20). Anand, et 
al. is silent regarding a TDS protocol that includes such a data field, as claimed, let alone 
identifying the number of pending requests known by the client device. Anand, et al. is 
only concerned with the current query issued by the script or application, and not the 
number of requests pending at a given time. 

Further, Jordan, II, et al. fails to teach or suggest such distinctive functionality, as 
claimed. Rather, Jordan, II, et al. relates to a process in the memory of a processor that 
purports to enhance memory allocation and memory copying during the process of 
reconstructing a data structure. {See col. 1, Ins. 29-32). Jordan, II, et al. teaches that a 
computer can construct a data structure on a first computer for use in accessing 
information from a database on a second computer by obtaining a memory requirement 
data structure from the database of the first computer and constructing a communication 
buffer containing the memory requirement data structure and information from the 
database. {See col. 1, Ins. 32-39). The communication buffer can then be transmitted to 
the second computer. {See col. 1, Ins. 39-40). The second computer determines the 
memory requirements for the data structure based on the information in the 
communication buffer, and a data structure is built based on the memory requirement 
data structure on the second computer using the memory already allocated to the 
communication buffer in the second computer. {See col. 1, Ins. 40-47). 

However, Jordan, II, et al. fails to teach or suggest a data field that identifies the 
number of pending requests known by the client and communicating such information to 
the server. Instead, Jordan, II, et al. teaches allocating memory on the server side in 
order to store a data string containing data structures being sent to the server, based on 
memory requirement information included in the communication buffer sent to the 
server. {See col. 2, In. 49 - col. 3, In. 1 1). Thus, Jordan, II, et al. does not relate to the 
number of pending requests, but rather the total amount of memory to be allocated for all 
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data in the data string that will be stored in and sent via the communication buffer of the 
client. (See id.) 

In contrast, the claimed subject matter can include a TDS protocol that includes a 
data field that can identify, to the server device, the number of pending requests known 
by the client device. The number of requests reported by the client can facilitate 
synchronizing the execution of requests currently pending between client and server. 
(See p. 3, Ins. 27-30). This can mitigate inconsistent server behavior related to instances 
where buffer zones are waiting to be read by the client. (See p. 3, Ins. 30-3 1). 

Additionally, amended claim 1 (and similarly independent claim 23) recites: the 
MARS header is employed to transmit, to the server device, the number of pending 
requests known by the client device to facilitate synchronization of execution of queries 
to facilitate communication between the client device and the server device, based at 
least in part on the number of pending requests known by the client device, regardless 
of buffer size for the client device and the server device. Anand, et al. and Jordan, II, et 
al, alone or in combination, fail to disclose these distinctive features of the claimed 
subject matter. 

Rather, Anand, et al. discloses marshaling a query, as opposed to synchronizing 
execution of queries, as in the claimed subject matter. Anand, et al. expressly defines 
marshaling as "the process of packaging up the data so that when it is sent from one 
process to another, the receiving process can decipher the data." (Anand, et al., col. 2, 
Ins. 10-12). Thus, Anand, et al. is only concerned with the process of packaging up data 
so that it can be deciphered when received. However, Anand, et al. does not address 
synchronizing execution of queries, which can relate to the timing of when a query is to 
be executed. 

Further, Jordan, II, et al. relates to allocating memory on the server side in order 
to store a data string containing data structures being sent to the server, based on memory 
requirement information included in the communication buffer sent to the server. (See 
col. 2, In. 49 - col. 3, In. 1 1). Thus, Jordan, II, et al. does not teach or suggest 
synchronizing the execution of multiple queries, but instead teaches communicating, to 
the server, the amount of memory to be allocated for a data string that is to be sent from 
the client to the server. 
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In contrast, the claimed subject matter can employ a MARS header that can 
transmit, to the server device, the number of pending requests known by the client 
device. Transmitting information regarding the number of pending requests to the server 
device, can facilitate synchronizing the execution of queries and can thereby facilitate 
communication between the client device and server device, as synchronization of the 
execution of queries can be based at least in part on the number of pending requests 
known by the client device. 

Further, Anand, et al. is silent regarding synchronizing execution of queries, 
based on the number of pending requests known by the client device. The Examiner 
correctly concedes this as the Examiner states that Anand, et al. "fails to explicitly 
disclose steps of based at least in part on the number of pending requests known by the 
client device regardless of buffer size for the client device and the server device ." (See 
Office Action dated January 4, 2007, p. 6, Ins. 20-21 ) (emphasis in original). However, 
the Examiner contends that Jordan, II, et al. discloses such functionality of the claimed 
subject matter. (See Office Action dated January 4, 2007, p. 6, Ins. 21-25). Applicants' 
representative respectfully submits that the Examiner's contention is erroneous. 

Rather, Jordan, II, et al. teaches sending information from the client to the server 
regarding an amount of memory to be allocated by the server to accommodate the data 
string being communicated to the server, so that the server can allocate the required 
amount of memory to receive the data string. (See col. 2, In. 49 - col. 3, In. 18). Jordan, 
II, et al. simply identifies the amount of memory to be allocated by the server, and not the 
number of pending requests known by the client. 

Moreover, the Examiner concedes that Anand, et al. fails to disclose: regardless 
of buffer size for the client and the server, as claimed. (See Office Action dated January 
4, 2007, p. 6, Ins. 20-21). The Examiner contends, however, that Jordan, II, et al. 
discloses "buffer size for the client device and the server device." (See Office Action 
dated January 4, 2007, p. 6, Ins. 22-28). 

However, the claimed subject matter comprises a MARS header that can be 
employed to synchronize execution of queries regardless of buffer size for the client and 
the server. Jordan, II, et al. fails to disclose this distinctive feature of the claimed subject 
matter. 
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Jordan, II, et al. relates to a process in the memory of a processor that purports to 
enhance memory allocation and memory copying during the process of reconstructing a 
data structure. (See col. 1, Ins. 29-32). Jordan, II, et al. only discloses that the server can 
calculate the total memory space needed for data structures based on the size of a 
communication buffer. (See col. 5, Ins. 8-17). The mere mentioning of a size of a 
communication buffer does not disclose, teach or suggest "regardless of buffer size for 
the client device or the server device," as in the claimed subject matter. Quite to the 
contrary, Jordan, II, et al. is very much concerned with the size of the communication 
buffer, as the memory needed and the size of the buffer are both examined to determine 
whether the size of the buffer is sufficient to meet the memory needs. (See col. 5, Ins. 8- 
17; col. 6, Ins. 21-38; and Fig. 4). 

Conversely, the claimed subject matter is not concerned with the buffer size, as it 
relates to synchronizing execution of queries, regardless of buffer size for the client 
device and the server device. 

In view of at least the foregoing, Anand, et al. and Jordan, II, et al., alone or in 
combination, do not disclose, teach, or suggest each and every element recited in 
independent claims 1 and 23 (and associated dependent claims 2, 4-9, and 26-28). 
Accordingly, it is believed that the subject claims are in condition for allowance, and the 
rejection should be withdrawn. 

IV. Rejection of Claims 3, 10, 29, and 30 Under 35 U.S.C. $ 103(a) 

Claims 3, 10, 29, and 30 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Anand, et al. (US 5,974,416) in view of Jordan, II, et al. (US 
5,412,805) and further in view of Clegg, et al. (US 6,356,946) ("Clegg, et air). This 
rejection should be withdrawn for at least the following reason. Anand, et al., Jordan, II, 
et al., and Clegg, et al., alone or in combination, do not disclose, teach, or suggest all the 
limitations of the subject claims. Claims 3, 10, 29, and 30 depend from independent 
claim 1 . Clegg, et al. fails to cure the aforementioned deficiencies of Anand, et al. and 
Jordan, II, et al. with respect to independent claim 1. Accordingly, it is believed that 
claims 3, 10, 29, and 30 are in condition for allowance, and the rejection should be 
withdrawn. 
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Conclusion 

The present application is believed to be in condition for allowance in view of the 
above comments and amendments. A prompt action to such end is earnestly solicited. 

In the event any fees are due in connection with this document, the Commissioner 
is authorized to charge those fees to Deposit Account No. 50-1063[MSFTP619US]. 

Should the Examiner believe a telephone interview would be helpful to expedite 
favorable prosecution, the Examiner is invited to contact applicants' undersigned 
representative at the telephone number below. 



Respectfully submitted, 
Amin, Turocy & Calvin, llp 

/HlMANSHU S. AMIN/ 

Himanshu S. Amin 
Reg. No. 40,894 

Amin, Turocy & Calvin, llp 
24 th Floor, National City Center 
1900 E. 9 TH Street 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 
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